…iaskrgr

Rollup of 8 pull requests

Successful merges:

 - rust-lang#124297 (Allow coercing functions whose signature differs in opaque types in their defining scope into a shared function pointer type)
 - rust-lang#124516 (Allow monomorphization time const eval failures if the cause is a type layout issue)
 - rust-lang#124976 (rustc: Use `tcx.used_crates(())` more)
 - rust-lang#125210 (Cleanup: Fix up some diagnostics)
 - rust-lang#125409 (Rename `FrameworkOnlyWindows` to `RawDylibOnlyWindows`)
 - rust-lang#125416 (Use correct param-env in `MissingCopyImplementations`)
 - rust-lang#125421 (Rewrite `core-no-oom-handling`, `issue-24445` and `issue-38237` `run-make` tests to new `rmake.rs` format)
 - rust-lang#125438 (Remove unneeded string conversion)

r? `@ghost`
`@rustbot` modify labels: rollup

Rollup merge of rust-lang#124297 - oli-obk:define_opaque_types13, r=jackh726

Allow coercing functions whose signature differs in opaque types in their defining scope into a shared function pointer type

r? `@compiler-errors`

This accepts more code on stable. It is now possible to have match arms return a function item `foo` and a different function item `bar` in another, and that will constrain OpaqueTypeInDefiningScope to have the hidden type ConcreteType and make the type of the match arms a function pointer that matches the signature. So the following function will now compile, but on master it errors with a type mismatch on the second match arm

```rust
fn foo<T>(t: T) -> T {
    t
}

fn bar<T>(t: T) -> T {
    t
}

fn k() -> impl Sized {
    fn bind<T, F: FnOnce(T) -> T>(_: T, f: F) -> F {
        f
    }
    let x = match true {
        true => {
            let f = foo;
            bind(k(), f)
        }
        false => bar::<()>,
    };
    todo!()
}
```

cc rust-lang#116652

This is very similar to rust-lang#123794, and with the same rationale:

> this is for consistency with `-Znext-solver`. the new solver does not have the concept of "non-defining use of opaque" right now and we would like to ideally keep it that way. Moving to `DefineOpaqueTypes::Yes` in more cases removes subtlety from the type system. Right now we have to be careful when relating `Opaque` with another type as the behavior changes depending on whether we later use the `Opaque` or its hidden type directly (even though they are equal), if that later use is with `DefineOpaqueTypes::No`*